Add tests/apps, a new package for application-lifecycle scenarios that
are not about networking, holding evetest equivalents of three eden
smoke tests (tests/eclient/testdata/{metadata,userdata,app_logs}.txt):

- TestAppInstanceMetadata: an app POSTs a payload to the link-local
  metadata server and EVE must report it to the controller as
  ZInfoAppInstMetaData. Also covers the appCustomStatus endpoint, to
  check that the reported metadata type follows the endpoint used, and
  the hostname endpoint.

- TestAppUserData: ~90 KB of plain key=value user-data must not break
  deployment and must reach the container as environment variables;
  a #cloud-config document must have its write_files section applied,
  exactly once per user-data version, so that a file modified by the
  application survives an application restart.

- TestAppLogs: application stdout must reach the controller, both the
  output produced at container creation and the output produced while
  the app runs, and collection must resume after the app is stopped and
  started again.

All three are registered in TestApplicationSuite and share the same
device and network requirements so the framework reuses a single VM
across the suite.

Signed-off-by: Renê de Souza Pinto <rene@renesp.com.br>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Add tests/telemetry, a new package covering the three channels through
which EVE reports itself to the controller, holding evetest equivalents
of three eden smoke tests (tests/lim/testdata/{log,info,metric}_test.txt):

- TestDeviceInfo: ZInfoDevice must report the port configuration EVE
  actually applied, a plausible hardware inventory, and an HSM state
  matching how the device was created.

- TestDeviceMetrics: DeviceMetric must report moving per-port network
  counters, plus the memory, CPU and controller-connectivity counters
  carried in the same message. Note that NetworkMetric.iName is the
  logical label from the controller config, not the interface name;
  eden matched it against eth0 only because its device model labels the
  port that way, so iName and localName are asserted separately here.

- TestDeviceLogs: a message emitted on the device must reach the
  controller, and the microservice log stream must be flowing. Eden
  drives SSH connections and waits for sshd's "Disconnected from"
  message; that trigger was tried here and does not work -- the sessions
  are established but no matching entry is ever uploaded. This test
  instead emits a per-run marker to /dev/kmsg, the path EVE's own
  ssh-service.sh uses with the comment "this is picked up by newlogd",
  which makes the trigger deterministic and independent of third-party
  log wording. The kernel log path is gated by debug.kernel.*.loglevel,
  separate from the debug.default.* levels the framework sets, so the
  test states those explicitly.

Fields that EVE populates conditionally are waited for inside the
Eventually predicate rather than asserted on whichever message arrived
first: DevicePort.Err is never nil (zedagent encodes port test results
into it unconditionally, so "no error" means an empty description), and
DeviceMemory/CpuMetric.TotalNs only appear once domainmgr has published
the host DomainMetric.

All three are registered in TestTelemetrySuite and state identical
device requirements so the framework reuses a single VM across the
suite.

Signed-off-by: Renê de Souza Pinto <rene@renesp.com.br>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>